前一篇討論「BM25 為什麼可能打贏 Vector：第一輪 Error Analysis」，這篇聚焦「Chunking 不是越碎越好：文件單位如何改變檢索」，並沿用同一組輸入、環境與判讀規則，避免只做名詞比較。

今天要回答的問題

比較 section／fixed-size／semantic chunk 等策略對 recall、ranking 與 context 完整性的影響。

工程邊界

Corpus Hygiene 是最便宜的 Retrieval 提升

重複文件、過期版本、空白頁、導覽列、權限不該公開的資料、OCR 噪音與錯誤 metadata 都會直接污染 retrieval。Embedding 不會自動把垃圾資料「洗乾淨」。

進入索引前應至少做去重、版本選擇、格式正規化、語言／來源標記、權限 metadata 與內容 hash。之後任何實驗都要能說明使用的是哪一版 corpus。

一個可以直接重現的起點

今天的實作原則

驗證時先固定環境與輸入，每次只改一個變因，並同時記錄操作方法與判定標準。

只替換 Chunking 策略

這裡以「只改 chunking 策略並重建 index」為比較目標，只保留 baseline、candidate 與逐項差值；evaluate 再接到實際評測程式。

METRICS = ('chunk count', 'Hit/MRR/NDCG', 'index size', 'latency')
baseline = evaluate("baseline", metrics=METRICS)
candidate = evaluate("candidate", metrics=METRICS)

for metric in METRICS:
    delta = candidate[metric] - baseline[metric]
    print(f"{metric}: {delta:+.4f}")

驗證與落地方式

驗證可從「只改 chunking 策略並重建 index」開始。比較前先凍結 corpus、query set、qrels、資料切分與評測程式，確保實驗只改動目標元件。若 index、候選數或前處理同時改變，最後的分數差異就無法歸因，容易把資料變動誤認成模型進步。

這篇優先比較：chunk count、Hit/MRR/NDCG、index size、latency。除了整體平均，也要保留逐題結果與 query 類型，分辨改善集中在哪些情境、哪些案例反而退步。品質指標還要和 latency、記憶體、索引大小或單次成本一起閱讀，才能判斷提升是否值得帶進 production。

常見誤判

• 只公布最高分，沒有保留 baseline、負面結果與信賴區間，難以判斷改善是否穩定。
• 在相同資料上反覆調參又回頭評分，test set 會逐漸變成隱性的 training set。
• 只看 retrieval 或 generation 的單層指標，忽略錯誤可能沿 pipeline 傳遞，也可能被後段暫時掩蓋。

上線前檢查

每次實驗都應能追回資料版本、模型、index、config 與評測程式版本。上線前再以未參與調參的案例做一次回歸測試，並保留最差案例供 error analysis。若品質提升不足以抵銷延遲、成本或維護複雜度，維持較簡單的 baseline 通常更可靠。

如何閱讀結果

結果應先看逐題變化，再看整體分數。若平均值上升，卻只來自少數容易題，或關鍵 query 類型持續退步，仍不適合直接替換 baseline。每個明顯升降的案例都應回到候選文件、排名與輸入特徵，確認變化符合原先假設。

離線評測通過後，還要檢查線上條件：新文件加入後是否需要重建 index、cache 是否造成舊結果、查詢分布是否漂移。只有資料生命週期也能被管理，實驗中的品質提升才可能持續。

結果判讀

判讀不只看最大或最漂亮的數字。這一天真正要回答的是：找出過碎、過長與答案跨 chunk 的代價。

如果核心指標改善，但錯誤率、尾端延遲、資源成本或恢復能力變差，這代表取捨，而不是無條件進步。相反地，沒有改善也不是無效結果；至少能排除一條看似合理、實際上不值得增加複雜度的路。

今天的結論

今天的工程判斷是：找出過碎、過長與答案跨 chunk 的代價。無論結果支持或否定原本假設，都必須保留完整條件，才能和下一天的實驗串在一起。

下一篇將處理：Query Normalization 與 Metadata Filtering：便宜但常被忽略的提升。

參考資料

• BEIR Benchmark
• Sentence Transformers Documentation
• ir-measures
• RAGAS Documentation